-
Notifications
You must be signed in to change notification settings - Fork 12
feat(autojac): Use jac_to_grad to aggregate .jac fields #510
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
48c27b2 to
99b4260
Compare
|
We have something a bit tricky: both To reuse some code in two different packages (
|
|
Lastly, it's very annoying to have this Pylance error all over the place: I'm not sure how we could reliably stop showing this error, or even use a custom tensor that would properly fix this. |
I think this is just because all this is bad design. We made it more torch compatible, and this is the price. Pylance is right, there is not field |
Yeah but there are still ways to make it much cleaner. I'm working on something. |
I think we should keep in mind that we would like the users to have a good typing experience. It would be nasty to make them use |
712667c to
7dda66f
Compare
Well, they should rarely need to use these |
|
right, that's very good, and if they do, they should get some amount of warning. You can delete the discussion if you want (annoying that we cannot have a thread). |
@PierreQuinton this was a big issue that we didn't spot earlier. I don't think the jacobian_matrix can be a view of the concatenated jacobians, so I think that having both the individual matrices + the combined matrix alive at the same time means using double memory. With this _free_jacs call much ealier, if the garbage collector is reactive, we shouldn't have this issue of doubling the peak memory usage for no reason. I think we should check that this PR doesn't introduce a huge memory efficiency regression. Can't merge without doing that.
These functions really are wrappers around assert_close, so we'd like them to always also take the parameters of assert_close, even if those change in the future, and to have the same default values. So I think kwargs is justified here. Also it's not user facing so the lack of documentation of the expected types will not be visible.
Uh oh!
There was an error while loading. Please reload this page.